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Abstract— A high assurance architecture is described for the protection of 
distributed multilevel secure computing environments from malicious code 
and other attacks. Component security services and mechanisms extend and 
inter-operate with commodity PCs, commodity client software, applications, 
trusted components, and legacy single level networks, providing new 
capabilities for composing secure, distributed multilevel security. This 
architecture results from the realization that unless a secure system offers 
users comfortable and familiar interfaces for handling routine information, it 
will fail due to lack of user acceptability. 

I.lNTRODUCTION 

There is a growing need to support mandatory enforcement 
of confidentiality and integrity policies in hostile envi¬ 
ronments. Applicable environments include: military coali¬ 
tions, responses to security emergencies at home, and busi¬ 
ness and financial relationships. Neither military computer 
systems and networks nor their commercial sector equiv¬ 
alents, are currently organized to provide high assurance 
support for multilevel security policy enforcement and ad¬ 
equate defense against increasingly sophisticated attacks. 
Thus we risk corruption of critical data and systems, leakage 
of sensitive information, and degradation of service to 
fundamental infrastructure systems. Industrial systems run 
the risk of economic espionage, while the lack of policy 
support for Joint Command and Control Systems constrains 
military operations. As shown in Table I, attacks against 
modern systems range from trivial to grave. 

To secure mission critical information systems, new trusted 
computing approaches are required, involving both 
interoperable system security features and standardized se¬ 
curity mechanisms. We describe an innovative high assurance 
architecture to provide trusted security services and 
integrated operating system mechanisms that can protect 
distributed multilevel secure computing environments from 
malicious code and other attacks. These security services and 
mechanisms extend and interoperate with existing ap¬ 
plications and commodity clients, providing new capabil¬ 
ities for composing secure distributed systems using com- 
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mercial off-the-shelf (COTS) components. The latter ob¬ 
jective results from the realization that unless a secure system 
offers users the same comfortable and familiar interfaces used 
for handling routine information, it will fail due to lack of 
acceptability. 

The Monterey Security Architecture (MYSEA) provides a 
trusted distributed operating environment for enforcing 
multilevel security policies, and utilization of support for 
incorporation of unmodified commodity productivity ap¬ 
plications for user activities. It encompasses many low- 
assurance commercial components and relatively few spe¬ 
cialized high-assurance elements. This arrangement permits 
the ongoing investment in commodity personal computer 
(PC) operating systems and applications to be integrated into 
an environment where enforcement of critical security 
policies is assigned to more trusted elements. Assurance is 
derived from the application of high assurance system design 
and development methods to the trusted elements as well as 
to the overall architecture. 

The locus of policy enforcement in MYSEA is a high 
assurance platform, currently the DigitalNet XTS-400. We 
have vertically integrated application security requirements 
with underlying security services, and can apply an existing 
Quality of Security Service model and framework [1] to the 
integrated security structure. Additionally, MYSEA supports 
secure trusted path communications between the user and the 
trusted OS, as well as high assurance labeling for incoming 
traffic from legacy single level networks. 

The state of the art for protecting multilevel information 
and for the management of security policies and security 
services in support of critical applications is advanced 
through several innovations: 

• A distributed architecture for isolating trusted compo¬ 
nents in support of commercial and open source applications. 
The innovative use of add-on trusted components in 
commercial client-server systems can potentially magnify the 
impact of highly trusted systems. 

• A trusted path mechanism for assured, unambiguous user 
communication with the trusted computing base, which does 
not depend upon client workstation security. 

• Techniques for vertical integration of security policy 
control functions with underlying security services in a 
Quality of Security Service framework. 
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TABLE I 

Attack Elements and System Assurance Required for Defense. 


Attack Motive 

Attack Strategy 

Attack Resources 

Threat 

Assurance Required 

Political-Military 

Long-Term Planning 

Well Funded 

System Subversion 

Highest 

Political-Military 

Mid-Term Planning 

Modest to High 

Malicious Code 

Trojan Horses 

High 

Malicious Amusement 

Short-Term Planning 

Low to Modest 

Flaw Exploitation 

Modest 

Malicious Amusement 

Ad Hoc 

Low 

Interface Exploitation 

Low 


• Secure single level connections to existing classified net¬ 
works. These connections may be initiated either from clients 
within the multilevel network to access single level resources, 
or from existing single level networks to access resource on 
the multilevel server. 

II. Monterey Security Architecture 

MYSEA is a distributed client-server architecture featuring 
a combination of (relatively few) specialized policy enforcing 
components and multiple open source and commercial off- 
the-shelf components. The major physical components of the 
architecture are illustrated in Figure 1: 

• High assurance MYSEA Servers which provide the locus 
for multilevel security policy enforcement and host various 
open source or commercial application protocol servers, 

• Security enhanced clients comprised of commodity PCs 
executing popular commercial software, along with Trusted 
Path Extensions that provide trustworthy policy support 
mechanisms and thus permit distribution of server-enforced 
security policy across the network, and 

• Existing classified single level networks connected to the 
high assurance multilevel servers. Complementing link en- 
cryptors, trusted components ensure proper labeling of and 
protection data passing back to the multilevel server. 

The MYSEA Server enforces the security policy and con¬ 
trols access to information. A unified mandatory access 
control policy for both confidentiality and integrity policy is 
enforced by the server. It combines the Bell and La-Padula 
[2] and strict Biba [3] policies. The system supports read- 
down policies; support for regrading policies must be 
implemented in trusted applications that use, and are con¬ 
strained by, the underlying kernel. Its core is the TCSEC [4] 
Class B3 evaluated DigitalNet XTS-400. (It is currently 
undergoing a Common Criteria [5] evaluation.) We have 
augmented the existing TCB with services to support high 
assurance remote client authentication, session management, 
and connection to legacy single level networks. A suite of 
application protocol services, including SMTP, IMAP, and 
HTTP, has been ported to the multilevel server. These 
application protocol servers provide services and interfaces to 
shared resources along with multilevel views of information 
to clients. When the augmented TCB is combined with 
untrusted, but policy constrained (and, in some instances, 
policy aware) application protocol servers, the result is the 


MYSEA Server. MYSEA clients are PCs equipped with a 
Trusted Path Extension device that provides local MYSEA 
policy support. Trusted Channel Modules provide high 
assurance labeling of information entering the multilevel 
server from legacy single level networks. The MYSEA 
Server(s) communicate only with each other, with 
TrustedPathExtension(s) (TPE),or withTrusted Channel 
Module(s) (TCM) or single level networks with static 
sensitivity designations. Other components connected to the 
network will be ignored. (Note: encryption devices may also 
be added to the network.) Multiple MYSEA Servers provide 
scalability within the desired security policy perimeter. 

A. MYSEA Concept of Operation 

Using the Trusted Path Extension at the PC allows users to 
log on to the MYSEA system by way of a trusted path. This 
establishes an identity for audit and access control purposes, 
and then establishes session security attributes such as current 
session level. Subsequently, the user can log on to the native 
client OS at the PC and use (1) standard commercial client 
software (e.g., web browser or e-mail program) to access 
applications supported by the MYSEA Server or by servers 
on a connected single level existing network, or (2) use any 
applications on the local PC. From the PC the user can access 
any level of server data allowed by the security policy (for 
example, reading domains of data that are lower in sensitivity 
than the negotiated session level) as well as access locally 
created data. By again invoking the trusted path, the user can 
request to modify session security attributes, such as session 
level. During such negotiations, the Trusted Path Extension 
ensures that client access to the network is blocked. 

B. MYSEA Components 

MYSEA consists of the following component hierarchy: 

• MYSEA Server 

-Policy-aware application protocol servers 
-High Assurance Multilevel Platform 

* trusted path services 

* security support service 

* secure session services 

* quality of security services (QoSS) 
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* cryptographic services 

* multilevel security kernel 

• MYSEA Client 
-Trusted Path Extension 
-COTS PC, including unmodified: 

* operating system 

* user interface 

* applications 

* network connections 

• Existing Single Level Networks -pre-existing single level 
servers and clients 

-high quality encryption to the MYSEA Server 
-Trusted Channel Module 

B.l MYSEA Server 

Each MYSEA Server consists of the DigitalNet STOP 
operating system [6], which enforces critical multilevel se¬ 
curity policies, multilevel services to support distributed high 
assurance, and assorted untrusted application server 
instances. Constrained by the policy enforcement mecha¬ 
nisms of the underlying security kernel, application servers 
play no role in mandatory policy enforcement, and are 


functionally equivalent in terms of overall application-level 
protocol support to a commodity application server for the 
particular protocol provided. Thus, each application server is 
compatible with existing commodity client packages. Ad¬ 
ditionally, information managed by application servers can be 
organized to support such sharing as allowed by the kernel 
policy, as well as advisory labeling. 

B.2 Server TCB 

The foundation for the server TCB (depicted in Figure 2) is 
the DigitalNet STOP security kernel. The STOP kernel 
creates labeled protection domains and associates security 
attributes with active and passive entities exported at its 
interface. The DigitalNet system provides multilevel secure 
file system support, which provides for the global and 
persistent separation of data into its respective domains. 
Other security services that have been integrated into the 
trusted system are described below. 

B.3 Trusted Path Services 

Native XTS-400 trusted path support for local terminals has 
been supplemented with trusted path services for remote 
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MYSEA clients. Trusted Path Services maintains the state of 
the user-to-MYSEA interaction; for example, a user may be 
logged in with default security attributes, but may not have 
started a session executing untrusted application code. For 
remote entities, Trusted Path Services provides an interface to 
the Security Support Services component to support 
identification and authentication, negotiation of domain or 
domain range, password modification, account creation and 
deletion, and user security attribute maintenance. Once a 
session has been established, the Trusted Path Services 
provides a distributed Session Status Database to the Secure 
Session Services component. 

B.4 Secure Session Services 

The Secure Session Services (SSS) component is used to 
launch instances of untrusted, constrained application pro¬ 
tocol servers and remote client-side applications. It provides 
trusted policy-sensitive services, with functionality similar to 
that of classic inetd implementations and supports standard 
application protocol transmissions. The SSS accesses the 
Session Status Database, maintained by the Trusted Path 
component, to determine the security attributes to associate 
with each application protocol server. 

This Session Status Database contains tuples that uniquely 
identify the user, the client associated with the user, the status 
of the user session, the security attributes of the session, and 
other security relevant information. Through a session status 
communication mechanism, information in the Session Status 
Database can be provided to distributed multi-policy 
platforms, thus providing a single sign-on and session level 
capability. 

B.5 Quality of Security Service Support 

For dynamic management of its security and performance 
characteristics, the QoSS Manager is the external QoSS 
interface to MYSEA. It governs security and performance 
factors of the various MYSEA components. The QoSS 
security and connectivity database is managed by the QoSS 
manager on the MYSEA server, and is distributed to the 
TPEs and TCMs, as needed. 

The QoSS manager provides a user interface so that de¬ 
cision makers can set the security posture of the network. 
This simple interface hides the underlying complexity of the 
QoSS mechanisms [7]. 

B.6 Constrained Application Protocol Servers 

The Secure Session Server provides instances of standard 
protocol servers for each client or for equivalence classes of 
clients. The Session Status Database is used to assign security 
attributes to protocol servers launched on behalf of requesting 
clients. Thus, protocol servers are assigned security levels 
reflecting the policy enforced by the underlying security 
kernel. 


Application Protocol Server 1 
Domain A 

Application Protocol Server 2 
Domain B 

High Assurance Multilevel Secure 

XTS-400 

TCB 

Secure Session Services 

Trusted Path Services 


Quality of Security Security Support 
Service Services 

Cryptographic Services 


Fig. 2. MYSEA Server. 

Protocol servers can take two forms. The first is a standard, 
policy-unaware protocol server restricted to accessing files 
and other objects associated only with the current session 
level. The second type is policy-aware, e,g, a file system, [8] 
and is able to take advantage of security policy domain 
relations that permit limited modes of access to certain other 
domains (e.g., “read down” for mandatory confidentiality 
policies). 

Among the policy-aware application servers adapted to the 
MYSEA environment are: Internet Mail Access Protocol 
(IMAP) based on the University of Washington IMAP server 

[9] , Hypertext Transfer Protocol (HTTP) based on Apache 

[10] , and Simple Mail Transfer Protocol (SMTP) [11]. Little 
or no code modification was needed for adaptation to the 
multilevel environment. 

Other protocol servers can be more tightly integrated with 
the underlying TCB. For example the Network File System 
(NFS) [12] can be implemented either as an application or in 
an operating system layer above the security kernel. 

B.7 MYSEA Clients 

MYSEA clients consist of two physical components: a 
Trusted Path Extension and an untrusted personal computer 
(see Figure 3). The PCs are typical COTS products hosting a 
popular commercial operating system and a commercial 
application suite or a thin client that accesses remote 
applications. The application suite includes client software 
intended to access standard application protocol servers. For 
example, mail service clients might include: Lotus Notes, 
Outlook, or Netscape [11]. 

When a user chooses to change security-policy domains, 
certain policies require that information associated with the 
previous domain be purged from the untrusted PC, e.g. 
previous session information cannot be reused by subsequent 
sessions in conflict with the distributed security policy. To 
ensure that these object reuse requirements are met, clients 
are diskless , with sufficient volatile RAM-disk capability to 
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Open Source or COTS 

Trusted Pith Negotiated 
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Quality of Security Service 


C ryptog raphic Services 
Fig. 3. MYSEA Client 


support a wide variety of user applications. We have created 
a configuration of Windows XPEmbedded that we term 
stateless-professional. It can be booted from a non-writeable 
source into RAM. User preferences are to be stored on the 
MYSEA server. Thus a user may configure different 
preferences for different session levels and could have, for 
example, desktop advisory indicators of the current session 
level. 

B.8 Trusted Path Extension 

Not only do trusted elements of the MYSEA system pro¬ 
vide runtime policy enforcement, they also provide services 
for the enforcement of supporting policies. To create a dis¬ 
tributed TCB, the architecture includes a Trusted Path 
Extension (TPE) at each client. 

The TPE maintains its own self-protecting domain separate 
from the user and PC domains. The use of a separate 
processor for the TPE ensures that it cannot be subverted by 
malicious software on the PC. Architecturally, the TPE 
provides the PCs only access to the network. 

Currently, the TPE has a handheld form factor. The Trusted 
Path Extension performs IP network address translation for 
all IP traffic going between the PC and the LAN. User trusted 
path I/O occurs via the handhelds native keyboard and screen. 

Simplicity has been a primary design goal for the TPE. 
Theobjectivewas not toconstruct a second operating system 
for the PC; it does not require the complexity and rich set of 
services provided for a general purpose system. We are 
creating a high assurance separation kernel [13] to provide a 
minimal set of services for the TPE. 

The Trusted Path Extension can be viewed as a minimized 
system functioning as a drone in response to commands from 
the MYSEA server for controlling the PC and managing I/O 
with the user. The TPE, under MYSEA server direction, 
supports the following services: 

Secure Attention Key. This service permits users to initiate 
unambiguous communication with the XTS-400 trusted path 
services for unspoofable presentation and capture of security- 
critical data. The secure attention key causes a TPE state 
change such that an unforgeable communications path 


between the user and the security functions of the server (viz. 
a trusted path) is established. 

Trusted Path Services. When the trusted path is invoked, the 
user may elect to input security critical information, such as a 
password. The trusted path services ensure that prompts from 
the server are displayed and that an input mechanism for 
replies is available. 

Controlled LAN Access. Provide non-bypassable, controlled 
access to the LAN from the PC. Malicious software on the 
PC cannot bypass the TPE. 

Communications and Cryptographic Services. Provide pro¬ 
tected communication channels between the server and the 
TPE. These protected communications are baseduponpro- 
tocols that support both the establishment and maintenance of 
a trusted path and session-level communications, such as to 
initiate communication with the server (via the secure 
attention key), as well as to receive and to respond to 
commands from the MYSEA Server. 

Quality of Security Service (QoSS). Complex and adaptive 
networks may require security on demand. When conditions 
on the network change, requirements for security may also 
change. In response to a change notification, QoSS 
mechanisms located on the TPE can modify the protection 
services afforded an ongoing session. The selection of 
protection mechanisms for client-server communications may 
be based upon network conditions such as INFOCON mode. 
A version of IPSec adapted to provide automated, dynamic 
QoSS through the use of an enhanced version of a policy 
server such as Keynote [14] permits selection of protection 
mechanisms for MYSEA Servers. 

B.9 Trusted Channel Module 

Similar to the TPE, which provides a secure unforgeable 
connection between the user and the MYSEA Server, the 
TCMs primary function is to provide a secure unforgeable 
communication channel between a single level network and 
one or more MYSEA Servers. Once the TCM successfully 
authenticates with a MYSEA Server, all data arriving at the 
MYSEA Server from that network is properly labeled by the 
MYSEA server. This allows applications to run unmodified, 
thus enabling users to use familiar COTS applications. If 
required by the overall system security policy, high assurance 
encryption devices can be placed at various points in the 
MYSEA Architecture. 

III.MYSEA Developmental Assurance 

Our rigorous security engineering and development process 
[15] is intended to support high assurance evaluation of 
trusted components. Development begins with the capture of 
the threat model and the security policy to be enforced and an 
interpretation of that policy in terms of an abstract computer 
system. This results in a formal security policy model and 
subsequent evidence that policy enforcement objectives are 
met. In concert with the formal activities, the engineering 
team develops a series of specifications that ranges from 
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threat model and high level requirements to detailed 
implementation documents and code. The system 
requirements specification incorporates security in conjunc¬ 
tion with all other requirements. 

Starting with a threat model and a system requirements 
specification (see [15]), we developed a system architecture. 
From these, we derive functional specifications and a cor¬ 
responding detailed design specification for specific com¬ 
ponents. Concurrent development of requirements, func¬ 
tional, and design specification allow generalizable notions to 
be identified and abstracted for inclusion in the higher-level 
documents. Conversely, detailed items more appropriate for 
the lower-level specification can be moved down. All 
development undergoes analysis and testing. 

IV. RelatedWork 

The research defined in this paper builds on a variety of 
previous efforts. It extends work to construct a multilevel 
secure LAN [16], [17], [18], [19], [20], [9], [11], [21], [22], 
[23], [24]. This previous project resulted in development of 
prototype low assurance networking modules to support the 
following functions: (1) a trusted path between clients and the 
server, (2) session-level negotiation at the server from the 
clients, and (3) secure single-level session communications 
on the Ethernet for clients at different session levels (i.e., 
different domains communicate with the server through a 
single physical network device). 

A.User Access to Multilevel Secure Data via Commercial 
Workstations and Applications 

Hinke suggested the notion of a high assurance server to 
provide a locus of multilevel secure control to single level 
clients [25]. In that design sketch, clients were relegated to a 
single level and were connected to the multilevel server via 
single level network links. Although possibly useful in 
certain static situations, the architecture does not provide the 
flexibility inherent in the MYSEA design. By restricting the 
client to a single level throughout its lifetime, users must 
access multiple clients in order to manipulate information at 
several levels. In contrast, MYSEA allows clients to 
renegotiate session levels and users need only one client. 

Rushby and Randell [26] describe a design for a distributed 
secure system that utilizes trusted network interface units 
(TNIUs) to connect workstations at different access classes to 
a local area network, through which access to a distributed 
multilevel file server is provided. Identification and 
authentication of users, as well as session level negotiation 
via the TNIUs is also described. Over and above this 
functionality, the MYSEA architecture also allows a more 
general purpose client-server operating environment, 
whereby new application servers can be easily added to the 
system, and thin clients are easily supported. 

Various virtual machine monitor approaches have been 
suggested [27], [28], [29] for supporting COTS applications 
while reliably separating different domains of data. In gen¬ 


eral, for these approaches to be trustworthy requires both the 
use of strictly virtualizable hardware [30], and a trustworthy 
monitor mechanism for separating the activities of the virtual 
machines. Creating a monitor sufficiently trusted to both 
separate different domains of activity, and allow read-down 
to less sensitive domains (as does MYSEA) is all the more 
difficult. While at least one was designed to provide high 
assurance read-down capabilities [28], it was never fielded. 
The VMM approach remains problematic for separation of 
different domains of data because many current 
microprocessors are not strictly virtualizable [31], leading to 
complex software solutions, and because of the difficulty of 
creating a trusted monitor. 

Non-distributed approaches to support access to multilevel 
data via COTS applications have been proposed in Seaview 
[32], [33], Purple Penelope [34], and some VMM 

architectures (see above). In each of these approaches, a 
separate process is created for each security level. Purple 
Pennelope has limited assurance, as it runs as a user-level 
application wrapping Windows NT, and it does not support a 
modifiable session level. The others rely on an underlying 
reference validation mechanism that controls access to mul¬ 
tilevel data. The MYSEA project extends certain concepts 
from these projects into a distributed environment. 

Replication architectures [35] provide a simple technique to 
achieve near-term multilevel security by copying all in¬ 
formation at low security levels to all dominating levels. On a 
small scale, they may work rather well; on a large scale, in 
terms of both numbers of documents to be replicated and 
numbers of security levels to be replicated to, they are 
problematic. The preponderance of DoD information is either 
unclassified or designated sensitive but unclassified. Similar 
proportions hold in the commercial sector. Replication of vast 
amounts of data to all higher levels seems infeasible. 
MYSEA does not use replication as a fundamental 
mechanism, so it avoids these problems. 

The Naval Research Laboratory (NRL) Network Pump [36] 
was developed to allow messages from a low sensitivity level 
to be sent to a high sensitivity level, and to prohibit messages 
and other information from going in the reverse direction. 
Additionally, the NRL Pump has been proposed as part of an 
overall network architecture to provide a more general two- 
way connectivity between multiple subnets at different 
security levels, resulting in a multiple single-level (MSL) 
network [37]. Here, information is also processed by an 
automated filter-guard to allow policy-approved flows from 
higher to lower domains. The MSL network approach has 
several drawbacks that the MYSEA avoids: 

• The capital and administrative cost of separately main¬ 
tained local area networks (LANs) 

• The decidability challenge when attempting to provide 
an automatic and reliable information filtering mechanism 

• The cost of filter rule maintenance for changing policies 

• The technical challenge of filtering complex information 
structures, such as multimedia. 
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Starlight [38] was designed to support logically separate 
single-level workstations connected by a switch to data 
management subsystems at different (single) levels. Software 
associated with the switch ensures that the current level of the 
workstation matches the level of data subsystem indicated by 
the switch setting. Starlight also allows low confidentiality 
information to flow through the switch to high sessions, 
providing a “read-down” capability. This approach has the 
same basic drawbacks as the MSL network, described above. 

The Novell Trusted Workstation Partnership [39] defined 
an architecture for separating clients in different security 
domains with their Class C2 evaluated network software. An 
instantiation of this approach was developed to separate the 
different file system domains, but, neither the products nor 
detailed documentation are available. 

B. Other Multilev elVaviations 

The rulesetbasedaccesscontrol(RSBAC) system [40] is a 
Linux extension wherein ah security relevant system calls are 
routed through a central decision component. Access-control 
decisions are based on the type of access and on attributes 
attached to the calling subject and to the target to be accessed. 
RSBAC is not high assurance, has an incomplete policy for 
network connections and lacks the functionality of even Class 
B1 of the earlier TCSEC. 

The Security-Enhanced (SE) Linux project is an approach 
to controlling multiple information domains in an open 
source operating system [41], [42]. The Security-Enhanced 
Linux project has not yet defined several mechanisms 
provided by MYSEA: 

• Remote-client login to the trusted OS 

• Trusted path communications with the trusted OS 

• Changing a user session security level 

• A mechanism for assigning security-domain context to a 
newly received network connection 

• Trusted, rather than client, support for IPsec message 
labeling 

• Support for untrusted clients, i.e., clients not based on 
Security-Enhanced Linux. 

Content-based Information Security [43] relies on various 
authentication and cryptographic technologies to mediate 
user’s access to information, but provides no underlying basis 
of trust to ensure against subversion or malicious software 
that might corrupt or leak information. 

C. Trusted Path 

Trustedpathrefers to mechanisms that provide assurance 
that security-critical functions are provided by the realsystem 
rather than masquerading software. Commercial systems, 
such as Windows [44], Trusted Solaris [45], and XTS-400 
[46] have implemented trusted path mechanisms. In the case 
of Windows and Solaris, it is notable that the processing of 
security requests is handled, at least partially, outside of the 
system security perimeter (unless the entire system is 
included within that perimeter, thus nullifying any possible 


assurance arguments). In contrast to the MYSEA architecture 
trusted path mechanism, the XTS-400 does not support a 
remote trusted path. 

V.CONCLUSION 

The Monterey Security Architecture (MYSEA) provides a 
trusted distributed environment for enforcing multilevel 
security policies, and supports unmodified COTS produc¬ 
tivity applications. The architecture encompasses a com¬ 
bination of many (untrusted) commercial components and 
relatively few trusted multilevel secure elements. 

MYSEA introduces several innovations for protecting 
multilevel data and for managing security policies and se¬ 
curity services in support of critical applications, including: 

• A distributed high assurance multilevel architecture that 
utilizes commercial and open source applications. 

• A trusted path mechanism. 

• Techniques for vertical integration of security policy 
control functions with underlying security services. 

• Access to existing single-level networks. 

Our future plans include additions and enhancements to 
MYSEA. With a user-level port of the Network File System 
(NFS), we intend to develop a more privileged non-kernel 
domain version of NFS on the XTS-400. We are exploring 
multilevel SMB [47] services. We are extending our QoSS 
framework to the multilevel environment. We are 
investigating single sign-on support for simplified access to 
legacy systems and policy-enhanced remote login for users 
on existing single-level networks without the TPE. 

Our Trusted Computing Exemplar (TCX) Project [13] 
complements MYSEA. The TCX kernel will be evaluatable 
at EAL7 under the Common Criteria. The high assurance 
Trusted Path Extension and Trusted Channel Module will be 
used as early examples of the TCX kernel. 
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